Tipos de símbolos en los DFDs
(notación de Yourdon/De Marco)
1.- Introducción: Visión panorámica del AE. DFD
Adaptado del capítulo 2 de Gane, C. and T. Sarson, Análisis estructurado de sistemas. 1990, Buenos Aires: El Ateneo.
Sistema de distribución sin inventario
“Se trata de un sistema que sirve pedidos de libros a unos clientes, con la particularidad de que no mantiene un stock o inventario interno. El sistema puede agrupar los pedidos que clientes distintos hacen a un mismo editor, de manera que se puedan conseguir descuentos.”
Ejemplo
1.- Introducción: Visión panorámica del AE. DFD: Ejemplo Práctico
Diagrama de contexto
Análisis de los procesos del sistema
en principio, no son materiales, son datos
(Gp:) 0.
Sistema de
Pedidos
(Gp:) EDITOR
(Gp:) libros entregados
(Gp:) pedidos
(Gp:) CLIENTE
(Gp:) órdenes de compra
(Gp:) libros pedidos
? Aplicamos la visión sistémica
1.- Introducción: Visión panorámica del AE. DFD: Ejemplo Práctico
0. Sistema de pedidos
(Gp:) 1.
Verificar
validez
de pedido
(Gp:) pedidos
(Gp:) 2.
Armar
pedidos
a editores
(Gp:) pedidos en lote
(Gp:) 3.
Verificar
envío
de editores
(Gp:) libros pedidos
(Gp:) 4.
Asignar
libros a
pedidos
(Gp:) 5.
Armar
entrega
a clientes
(Gp:) pedidos por título
(Gp:) libros
recibidos
(Gp:) libros por
clientes
(Gp:) D CLIENTES
(Gp:) estado del crédito
(Gp:) dirección
(Gp:) D LIBROS
(Gp:) libros entregados
(Gp:) libros entregados = albarán + lista-novedades
(Gp:) ? DD
(Gp:) ? DD
(Gp:) libros recibidos = {título + cantidad}
(Gp:) pedidos válidos
(Gp:) D PEDIDOS
PENDIENTES
(Gp:) órdenes de compra
(Gp:) D ÓRDENES DE
COMPRA
1.- Introducción: Visión panorámica del AE. DFD: Ejemplo Práctico
“Es un conjunto de metadatos, es decir, de información (datos) sobre datos”
Contiene las definiciones de todos los elementos de los diagramas
Implementación
Manual
Procesador de textos
Base de datos
Automático e integrado
1.- Introducción: Visión panorámica del AE. Diccionario de Datos
Flujo de datos: entrega
Descripción: Conjunto de libros enviados por un proveedor a la biblioteca, basado en la relación que previamente había recibido.
Sinónimos: *** none ***
Componente de: *** none ***
Composición:
Libros
+ { Albarán }
Información de entrada y salida
Origen Destino
*** Off the diagram *** Compra libros
PROVEEDORES Biblioteca
1.- Introducción: Visión panorámica del AyDE. Diccionario de Datos
Visión panorámica AyDEDiccionario de Datos (III)
Almacen: Facturas
Descripción: Información, por número de factura, sobre facturas en el sistema actual.
Sinónimos: *** none ***
Composición:
@Número-factura
+ Fecha-factura
+ Dirección-cliente
+ { Número-producto
+ Cantidad-producto
+ Costo-unidad-producto }
+ Costo-envío
+ Tasa-de-descuento
+ Neto-factura
+ Estado-factura
Procesos asociados: Según DFD general
Proc_cancelación Proc_pago
Proc_consultas Adjuntar_albarán
Proceso: Verificar estado del socio
Número: 1.1.1
Descripción: Se examina si el socio no está sancionado
Miniespecificación:
Recibir “Socio ID” del socio
Leer “SOCIOS” para
Leer “Flag-de-precaución”
Si OK, enviar “Socio ID válido”
Complejidad: Prioridad:
Ratio de transacciones: Memoria requerida (Kb):
Tiempo de proceso:
1.- Introducción: Visión panorámica del AyDE. Pseudocódigo.
Diagramas E-R y DED (Diagrama de Estructura de Datos)
DED es, básicamente, un E-R limitado:
no relaciones ternarias
sólo cardinalidades 1:N
no atributos multivaluados ni compuestos
1.- Introducción: Visión panorámica del AyDE. Modelado de Datos
(Gp:) Diagrama E-R
(Gp:) Proyecto
(Gp:) Empleado
(Gp:) Departamento
(Gp:) asignado
(Gp:) pertenece
(Gp:) (1,n)
(Gp:) (1,1)
(Gp:) (0,n)
(Gp:) (1,m)
[EN2002] (Chen)
(Gp:) Asignación
(Gp:) Departamento
(Gp:) Empleado
(Gp:) Proyecto
(Gp:) requiere
(Gp:) tiene
(Gp:) pertenece
(Gp:) DED
1.- Introducción: Visión panorámica del AE. Ejemplo de E/R .
Técnicas para describir la lógica de los procesos primitivos
Lenguaje estructurado
Pre y post-condiciones
Tablas de decisión
Árboles de decisión
1.- Introducción: Visión panorámica del AyDE. Lógica de Proceso.
Lenguaje estructurado
SI la factura excede de 300€
SI la cuenta del cliente tiene alguna factura sin pagar más de 60 días, dejar la confirmación pendiente de este pago.
SI NO (la cuenta está en buen estado) hacer confirmación y factura
SI NO (la factura es de 300€ o menos)
SI la cuenta del cliente tiene alguna factura sin pagar más de 60 días hacer la confirmación, la factura y escribir un mensaje sobre informe de crédito
SI NO (la cuenta está en buen estado)hacer confirmación y factura
FIN-SI.
1.- Introducción: Visión panorámica del AyDE. Lógica de Proceso.
Pre y post-condiciones
(Gp:) Pre1 (la factura excede de 300€) Y (la cuenta del cliente tiene alguna factura sin pagar más de 60 días)
Pos1 (confirmación pendiente de este pago)
Pre2 (la factura excede de 300€) o (la cuenta del cliente no tiene ninguna factura sin pagar más de 60 días)
Pos2 (confirmación y factura realizadas)
Pre3 (la factura no excede de 300€) Y (la cuenta del cliente tiene alguna factura sin pagar más de 60 días)
Pos3 (confirmación y factura realizadas) Y (mensaje impreso sobre informe de crédito)
Pre4 (la factura no excede de 300€) Y (la cuenta del cliente no tiene ninguna factura sin pagar más de 60 días)
Pos4 (confirmación y factura realizadas)
1.- Introducción: Visión panorámica del AE. Lógica de Proceso.
Tablas de decisión
1.- Introducción: Visión panorámica del AyDE. Lógica de Proceso.
Árboles de decisión
Política contable
Factura excede de 300€
Factura menos de 300€
Cuentas impagadas más de 60 días
Cuentas en buen estado
(Gp:) Cuentas impagadas más de 60 días
(Gp:) Cuentas en buen estado
1. Dejar confirmación pendiente de los pagos debidos.
2. Hacer confirmación y factura
3. Hacer confirmación y factura y escribir mensaje sobre informe de crédito
4. Hacer confirmación y factura
1.- Introducción: Visión panorámica del AyDE. Lógica de Proceso.
¿Y después del AE?
DISEÑO ESTRUCTURADO (DE)
El diseño lógico de los requisitos del nuevo sistema de información se convierte en un modelo de la aplicación, plasmado en un DIAGRAMA DE ESTRUCTURA.
En el paso AE ? DE,
Análisis de transacciones
Análisis de transformaciones
Diseño Estructurado: DIAGRAMA DE ESTRUCTURA. Ejemplo de diagrama de estructuras
(Gp:) Informar
petición
(Gp:) Elaborar
informe
(Gp:) Rechazar
petición
(Gp:) Leer
peticiones
(Gp:) Consultar
stock
(Gp:) Recibir
peticiones
(Gp:) Evaluar
peticiones
(Gp:) informe préstamo
(Gp:) informe préstamo
(Gp:) pet rechazada
(Gp:) ok
(Gp:) pet préstamo
(Gp:) pet aceptada
(Gp:) pet aceptada
(Gp:) pet préstamo
(Gp:) Definiciones de la BD
Visión panorámica AEEsquema resumen
(Gp:) Diccionariode Datos
(Gp:) Diagrama de flujo de datos
(Gp:) PROC
(Gp:) B
(Gp:) Z
(Gp:) Y
(Gp:) X
(Gp:) W
(Gp:) V
(Gp:) A
(Gp:) PROC
(Gp:) PROC
(Gp:) PROC
(Gp:) PROC
(Gp:) FUENTE
(Gp:) DESTINO
(Gp:) D ALMACÉN DE
DATOS
(Gp:) Diagrama E-R (o DED)
(Gp:) Diagrama de estructuras
(Gp:) Paso al diseño
(Gp:) Descripcióndel proceso
(Gp:) Definición del FD
(Gp:) Definiciones de los módulos
(Gp:) Descrip.E. E.
2.- Diagramas de Flujo de Datos(DFDs)
Símbolos del DFD(notación Yourdon/De Marco)
(Gp:) P
(Gp:) Proceso
(Gp:) Entidad Externa
(Gp:) D ALMACÉN DE
DATOS
(Gp:) Flujo de eventos
(Gp:) Flujo de datos
Transformaciones o procesos (funciones, cálculo, selección)
Terminadores (Fuentes o Destinos)(personas, entidades)
Flujos de información(inputs-outputs)
Flujos de control (Ward & Mellor 85)
Ficheros o depósitos temporales de información (base de datos, armario, clasificador, etc.)
2.- Diagramas de Flujo de Datos
Símbolos del DFD(notación Métrica/SSADM)
(Gp:) Entidad
Externa
(Gp:) D
(Gp:) ALMACÉN DE
DATOS
(Gp:) Flujo de datos
Transformaciones o procesos
Terminadores (Fuentes o Destinos)
Flujos de información
Ficheros o depósitos temporales de información
(Gp:) Localización
(Gp:) Proceso
(Gp:) ID
2.- Diagramas de Flujo de Datos
Procesos
TRANSFORMACIÓN (cálculo, operación)
FILTRO(verificación fecha, validación transacción)
DISTRIBUCIÓN(menú, selección transacción)
(Gp:) P
(Gp:) Transformación
(Gp:) E2
(Gp:) E3
(Gp:) E1
(Gp:) S2
(Gp:) S1
2.- Diagramas de Flujo de Datos
Procesos (II)
Nombres únicos, significativos y concisos
Preferiblemente expresados en función de las entradas y salidas
Recomendación: verbo (no ambiguo) + objeto
Evitar verbos ambiguos procesar, gestionar, manejar…
“objeto” está definido en el DD
Los procesos se descomponen en “subprocesos”, hasta llegar a los procesos primitivos
2.- Diagramas de Flujo de Datos
Diagrama de contexto
Es el DFD más general de todos
Está formado por un solo macroproceso (el sistema), las entidades externas (fuentes y destinos) y sus relaciones con el macroproceso
Delimita el sistema y su entorno
2.- Diagramas de Flujo de Datos
Entidades externas
Señalan los límites del sistema y establecen sus relaciones con el entorno
P
Sistema
DESTINO
DESTINO
DESTINO
FUENTE
FUENTE
FUENTE
Los identificadores (nombres) de las entidades externas serán únicos, significativos y concisos
2.- Diagramas de Flujo de Datos
Flujos de datos
Los nombres de los FD deben ser únicos, significativos y concisos
Son datos, así que nómbralos como datos.
Pueden estar indistintamente en singular o en plural, ya que en los DFDs no se representan cantidades (Barranco 95)
Los nombres no sirven sólo para identificar los datos, sino también la información que se tiene sobre ellos
P.ej. Información (fecha-válida) > Información (fecha)
2.- Diagramas de Flujo de Datos
Flujos de datos (II)
Flujos de datos interactivos (dialog flows)
Cuando dos FD establecen un diálogo o comparten una acción de estímulo-respuesta, pueden dibujarse como un único FD de doble flecha, donde ambos extremos deben llevar el nombre del FD que representan.
(Gp:) P
(Gp:) Determinar
estado
pedido
(Gp:) respuesta estado pedido
(Gp:) petición estado pedido
(Gp:) denegación
crédito
(Gp:) P
(Gp:) Analizar
Petición
crédito
(Gp:) P
(Gp:) Aceptar pago
(Gp:) solicitud crédito
(Gp:) autorización crédito
(Gp:) recibo
(Gp:) pago
2.- Diagramas de Flujo de Datos
Flujos de datos (III)
Las flechas dobles con sentidos opuestos que transportan los mismos datos pueden sustituirse por flechas doblemente encabezadas
¡Pero sólo si transportan los mismos datos!
P
B
P
A
(Gp:) X
(Gp:) X
P
A
P
B
(Gp:) X
2.- Diagramas de Flujo de Datos
Flujos de datos (IV)
Se puede representar, si se desea, el FLUJO DE MATERIAL, usando flechas de trazo grueso
(Gp:) EDITORIALES
(Gp:) INTERVENTOR
(Gp:) P4
(Gp:) Enviar al dpto.
(Gp:) comprador
(Gp:) P1
(Gp:) Selecc. y
(Gp:) pedir nuevos
(Gp:) libros
(Gp:) P3
(Gp:) Registrar libros
(Gp:) nuevos
(Gp:) P5
(Gp:) Poner libros
(Gp:) nuevos en
(Gp:) estantes
(Gp:) P2
(Gp:) Examinar
(Gp:) nuevos libros
(Gp:) D2
(Gp:) ESTANTES
(Gp:) D3
(Gp:) INVENTARIO
(Gp:) D4
(Gp:) SIGNATURAS
(Gp:) D9
(Gp:) CARRITO
(Gp:) LIBROS NUEVOS
(Gp:) D1
(Gp:) LISTA MAESTRA
(Gp:) DE ISBN
(Gp:) nuevas ofertas
(Gp:) pedidos de libros nuevos
(Gp:) ajuste de inventario
(Gp:) ajuste de signaturas
(Gp:) nuevos libros
(Gp:) libros nuevos
(Gp:) libros nuevos
(Gp:) libros nuevos
(Gp:) libros nuevos
(Gp:) libros nuevos
(Gp:) libros nuevos
Notación Gane & Sarson
2.- Diagramas de Flujo de Datos
Flujos de datos (V)
Se pueden considerar flechas convergentes o divergentes, con un mismo nombre
P
B
P
A
número de cuenta
P
Validar
calle
P
Validar
cod postal
P
Validar
Telef.
calle
dirección cli
cod postal
telef
Observaciones:
Sólo los procesos pueden separar FD (Piattini et al. 96)No poner FD como señales de activación (Yourdon 89)
2.- Diagramas de Flujo de Datos
Flujos de datos (VI)
Notación System Architect. Ejemplos
FD divergentes (conectores XOR y AND)
(Gp:) P
(Gp:) Imprimir factura
cliente
(Gp:) P
(Gp:) Imprimir lista empaquetado
(Gp:) P
(Gp:) Determinar
prods.para enviar
(Gp:) XORcuando los datos son divididos en subconjuntos
(Gp:) datos de facturación
(Gp:) datos de empaquetado
(Gp:) datos de envío
(Gp:) P
(Gp:) Determinar prescripción
(Gp:) P
(Gp:) Rellenar prescripción
(Gp:) P
(Gp:) Actualizar registropaciente
(Gp:) ANDcuando todos los datos siguen por ambos caminos
(Gp:) prescripción
2.- Diagramas de Flujo de Datos
Flujos de datos (VII)
Notación System Architect. Ejemplos
FD convergentes (conectores XOR y AND)
(Gp:) P
(Gp:) Aceptar pago en metálico
(Gp:) P
(Gp:) Transferir pago
(Gp:) P
(Gp:) Aceptar pagoa crédito
(Gp:) XOR cuando los mismos datos provienen decualquier dirección
(Gp:) datos de pago
(Gp:) P
(Gp:) Confirmar historial de crédito
(Gp:) P
(Gp:) Concedertarjeta decrédito
(Gp:) P
(Gp:) Confirmar empleo
(Gp:) ANDcuando los subconjuntosson combinados en uno
(Gp:) historial de empleo
(Gp:) historial de crédito
(Gp:) historia combinada
2.- Diagramas de Flujo de Datos
Flujos de datos (VIII)
No lo sabemos, no importa:
Los aspectos procedurales no se manifiestan en los DFDs
Si tales aspectos son relevantes, se deben incluir en las miniespecificaciones
¿El proceso “pide” el FD “pedido”?
¿El proceso “necesita” ambos FD?
(Gp:) P
(Gp:) Evaluar pedido
criterios valoración
pedido
2.- Diagramas de Flujo de Datos
Flujos de control
En los DFDs no se muestra el control ni el orden de ejecución
No se puede mostrar:
Procesos que se realizan antes que otros
Sincronización
Periodificación
Extensiones al AE para sistemas en tiempo real:
(Ward & Mellor 85)
(Hatley & Pirbhai 87)
2.- Diagramas de Flujo de Datos
Almacenes de datos
Nombre único, significativo y conciso
Convenciones de nombres en los FD a/desde un almacén:
No lleva etiqueta
El FD se refiere a un paquete (instancia) completo de la información contenida en el almacén
La etiqueta es la misma que la del almacén
El FD se refiere a uno o más paquetes completos (instancias) de la información contenida en el almacén
La etiqueta es distinta de la del almacén
El FD se refiere a uno o más componentes (atributos) de una o más instancias del almacén
2.- Diagramas de Flujo de Datos
Consistencia DFD / E-R (MAP 95)
Para facilitar validaciones cruzadas entre DFDs y E-R (o DED)…
Correspondencia entre los almacenes de datos “principales” (permanentes) del DFD y las entidades del E-R
Cada almacén de un DFD representa una o varias entidades del E-R
Cada entidad del E-R pertenece a un único almacén principal de un DFD
2.- Diagramas de Flujo de Datos
Consistencia DFD / E-R (II)
ETIQUETA DE LOS ALMACENES
Según explosione a
Entidad de datos ? Plural nombre entidad
Diagrama E-R (o DED) ? Nombre diagrama
DEFINICIÓN DE LOS ALMACENES
Pocos almacenes
Para cada uno, diagrama E-R (o DED)
Tantos almacenes como entidades se hayan identificado
Preferible (si no hay muchas entidades)
2.- Diagramas de Flujo de Datos
Descomposición funcional
Cada proceso se puede explotar, refinar o descomponer en un DFD más detallado
El DFD de un sistema es realmente un conjunto de DFDs dispuestos jerárquicamente
Los niveles de la jerarquía están determinados por la descomposición funcional de los procesos
La raíz de la jerarquía es el “diagrama de contexto”, que es el más general de todos
2.- Diagramas de Flujo de Datos
Descomposición funcional (II)
(Gp:) P
(Gp:) f5
(Gp:) P
(Gp:) f4
(Gp:) P
(Gp:) f3
(Gp:) P
(Gp:) f2
(Gp:) P
(Gp:) f1
(Gp:) B
(Gp:) Z
(Gp:) Y
(Gp:) X
(Gp:) W
(Gp:) V
(Gp:) A
(Gp:) P
(Gp:) f45
(Gp:) P
(Gp:) f44
(Gp:) P
(Gp:) f43
(Gp:) P
(Gp:) f42
(Gp:) P
(Gp:) f41
(Gp:) Z
(Gp:) y2
(Gp:) x2
(Gp:) y1
(Gp:) x1
(Gp:) Y
(Gp:) X
(Gp:) P
(Gp:) Sist
(Gp:) B
(Gp:) A
(Gp:) FUENTE
(Gp:) DESTINO
2.- Diagramas de Flujo de Datos
Consistencia en el DFD
Cada proceso en un diagrama “padre” es una consolidación del DFD “hijo”
Balanceo de DFDs
Las E/S de un proceso “padre” deben corresponderse con las E/S del DFD “hijo” que lo explica
2.- Diagramas de Flujo de Datos
Descomposición paralela
Descomposiciones de funciones
Proceso en subprocesos (DFD)
Descomposición de flujos de datos
La regla de balanceo se aplica teniendo en cuenta la descomposición paralela
2.- Diagramas de Flujo de Datos
Descomposición paralela (II)
Ejemplo: pedido = autorización + cupón de pedido + pago
(Gp:) P6
(Gp:) P5
(Gp:) P4
(Gp:) P3
(Gp:) P2
(Gp:) P1
(Gp:) envío
(Gp:) pedido
(Gp:) P6.3
(Gp:) P6.2
(Gp:) P6.1
(Gp:) pago
(Gp:) envío
(Gp:) cupón de pedido
(Gp:) autorización
2.- Diagramas de Flujo de Datos
Jerarquía de DFDs
En un DFD completo cada proceso tiene un número único que lo identifica en función de su situación en la jerarquía
Cada DFD tiene también un número único que coincide con el proceso que describe
Las hojas o nodos terminales corresponden a “procesos primitivos” o indescomponibles
Para cada proceso primitivo existirá una miniespecificación.
(Gp:) Localización
(Gp:) Proceso
(Gp:) Proceso primitivo en Métrica
2.- Diagramas de Flujo de Datos
Jerarquía de DFDs (II)
(Gp:) P 1.2
(Gp:) Proceso A
(Gp:) B
(Gp:) A
(Gp:) P 1.2.3
(Gp:) f3
(Gp:) P 1.2.1
(Gp:) f1
(Gp:) Y
(Gp:) W
(Gp:) V
(Gp:) A
(Gp:) X
(Gp:) P 1.2.2
(Gp:) f2
(Gp:) DFD 1.2
2.- Diagramas de Flujo de Datos
Jerarquía de DFDsDFD 0
El primer diagrama general que sigue al de contexto es el número 0 por convenio
En el DFD 0 se hace una descomposición en subsistemas, es decir, se indican los procesos más importantes en el sistema
? Han de ser SUBSISTEMAS
2.- Diagramas de Flujo de Datos
Descomposición funcional y almacenes de datos
Los almacenes aparecen lo más tarde posible
En un nivel superior únicamente cuando son interfaz entre procesos
Una vez que aparezca en un DFD, el almacén aparecerá otra vez en cada DFD de nivel más bajo relacionado
2.- Diagramas de Flujo de Datos
Descomposición funcional y almacenes de datos (II)
P
B
P
A
D
FICH
(Gp:) P
(Gp:) A.2
(Gp:) P
(Gp:) A.1
(Gp:) D
(Gp:) FICH
(Gp:) P
(Gp:) B.2
(Gp:) P
(Gp:) B.1
(Gp:) D
(Gp:) FICH
2.- Diagramas de Flujo de Datos
Tamaño de la jerarquía de DFDs
Cada DFD debería tener alrededor de 7 procesos o menos (Miller 57)
En general, habrá varios niveles intermedios, dependiendo del tamaño y complejidad del sistema que se está modelando
¿Cuántos niveles son convenientes?
Yourdon: depende del problema
(Gp:) Diagrama de contexto / sistema
Diagrama de subsistemas
Diagrama de funciones
Diagrama de subfunciones
Diagrama de procesos (opcional)
(Gp:) Métrica
2.- Diagramas de Flujo de Datos
Reglas sintácticas en DFDs
El origen y/o el destino de un FD es siempre un proceso
Excepción: almacenes en el diagrama de contexto (Yourdon 89)
(Gp:) P
(Gp:) SIST. DE
(Gp:) INVESTIG. DE
(Gp:) MERCADOS
(Gp:) CENTROS DE
(Gp:) INVESTIGACIÓN
(Gp:) CLIENTE
(Gp:) CLIENTES
(Gp:) CORPORATIVOS
(Gp:) D
(Gp:) DATOS DEL
MERCADO
informes anuales
datos de investigación
datos del mercado
datos del mercado
2.- Diagramas de Flujo de Datos
Reglas sintácticas en DFDs (II)
Todo almacén y todo proceso tienen uno o más FD de E y uno o más FD de S
EXCEPCIÓN: un almacén puede no tener FD de salida, por simplificación (p.ej. BD Histórica)
RECOMENDACIÓN: si aparece un proceso fuente o sumidero, replantearse los límites del sistema
(Gp:) P
(Gp:) Sumidero
(Gp:) P
(Gp:) Fuente
2.- Diagramas de Flujo de Datos
Ideas útiles para construir el DFD
Identificar todos los elementos exógenos
Identificar sus relaciones con el sistema
Trabajar según alguna de las siguientes filosofías:
De inputs a outputs
De outputs a inputs
Desde una posición intermedia hacia delante o hacia atrás
2.- Diagramas de Flujo de Datos
Ideas útiles para construir el DFD (II)
Nombrar adecuadamente todos los objetos del DFD
Numerar adecuadamente procesos y diagramas
Realizar una correcta división en subsistemas (DFD 0)
Utilizar la descomposición funcional jerárquica hasta alcanzar las funciones primitivas
2.- Diagramas de Flujo de Datos
DFDs – Conclusiones
Valiosa herramienta de comunicación
Usuario, analista, diseñador, programador
Se puede combinar con el uso de prototipos
Fácil de entender y de aprender
Facilita las relaciones con el usuario
Amplia difusión
2.- Diagramas de Flujo de Datos
DFDs – Conclusiones (II)
Superado por las metodologías OO,
pero todavía vigente:
se enseña en 12 de 15 ppales. universidades españolas,casi todas en Chile
industria,
administración (Métrica 2.1 y 3),
cuerpo de conocimiento de ingeniería del software (SWEBOK, SEEK, etc.)
El control no aparece hasta el final de la especificación estructurada
No es inmediato el paso a la codificación y prueba ? Diseño estructurado
2.- Diagramas de Flujo de Datos
DFDs – Conclusiones (III)
Útil para el análisis y para el diseño del nuevo sistema
Más adecuado para el nivel lógico, aunque también puede ser adecuado para el nivel físico (indicando personas concretas, lugares geográficos, formatos de datos, etc.)
2.- Diagramas de Flujo de Datos
Diseño Estructurado
Introducción
Concepto y Principios del Diseño
Inicios del Diseño
Efectividad del Diseño
Módulo(laridad)
Abstracción
Refinamiento
Factores de calidad
Acoplamiento
Cohesión
Tipos de Acoplamiento
Tipos de Cohesión
Consideraciones para un Diseño de Calidad
Resultados del Diseño
2.- Diseño: Diagrama de Estructuras
Diseño Arquitectónico ( Diseño Preliminar)
Elementos Diagrama de Estructura
Partición Estructural de un Diagrama de Estructura
Estrategias de Diseño
Construcción del Diagrama de Estructura
2.- Diseño: Diagrama de Estructuras
“ El diseño es un proceso a través del cual los requerimientos establecidos en la fase de análisis deben traducirse en una representación -que se sugiere modular- del producto de software que se precisa construir y que se acompaña de los procedimientos en virtud de los cuales cada módulo debe llevar a cabo su tarea, y de las estructuras de datos que debe procesar”
Larry Constantine ‘78
Concepto y Principios del Diseño
El diseño estructurado es un método de configuración de la organización modular del software que se desarrolla a partir de los flujos de datos que contiene la especificación de requerimientos obtenida en la fase de análisis bajo enfoque estructurado. En este sentido, puede decirse que este enfoque consiste en el diseño de programas como estructuras de funciones únicas y de relativa independencia.
Concepto y Principios del Diseño
Efectividad del Diseño
Para poder evaluar la efectividad de una representación de diseño, es preciso establecer lo que se denomina en Ingeniería de software, "criterios para un buen diseño", entre los cuales es posible destacar los siguientes:
El diseño debe exhibir una organización jerárquica con mecanismos de control que no atenten contra la independencia relativa de cada componente de la jerarquía.
Efectividad del Diseño
– El diseño debe ser modular, esto es, el software debe estar particionado lógicamente en elementos que ejecuten funciones y subfunciones específicas.
- El diseño debe generar módulos que exhiban niveles adecuados de independencia funcional.
- El diseño debe obtenerse a partir de la especificación de requerimientos generada durante la fase de análisis.
– Módulo(laridad)
– Abstracción
– Refinamiento
Efectividad del Diseño
– Módulo(laridad)
“Módulo es una unidad claramente definida y manejable que forman parte de los elementos constituyentes del software”
“La modularidad consiste básicamente en el particionamiento del software en elementos con nombres y direcciones separadas que se denominan módulos, los cuales en su composición generan la totalidad que debe ser capaz de resolver el problema global que da origen a la necesidad de construir un producto de software. “
Tiene que ver con la separabilidad de las funciones que en conjunto cumplen un objetivo mayor, esto es, responden a la idea de totalidades emergentes propia de la noción de sistemas.
Efectividad del Diseño
– Beneficios de la Modularidad
– Programas más simples, ya que puede ser comprendido, verificado, programado, depurado, mejorado y alterado por partes.
– Módulos que pueden ser desarrollados con relativa independencia.
– Disminución de la posibilidad de errores al reducir la complejidad.
– Programas que pueden evaluarse por partes, por lo cual todo test se hace más fácil.
– Programas más fáciles de alterar ya que son menores las líneas de código a considerar para incorporar los cambios.
– Módulos de función única que pueden ser reutilizados.
Efectividad del Diseño
– Beneficios de la Modularidad
– La posibilidad de cometer errores por parte de los programadores disminuye porque son menos las líneas de código que deben enfrentarse al mismo tiempo.
– La rotación de personal se hace menos crítica, ya que los programadores están involucrados en unidades de código más pequeñas por lo cual la sustitución resulta menos dificultosa.
– Responder al requerimiento de la división del código en segmentos de una página, como lo sugiere la programación estructurada, es casi total.
Efectividad del Diseño
– Módulo
El Fan-out es una medida del número de módulos controlados directamente por otro módulo (número de subordinados inmediatos que posee). El Fan-in indica cuántos módulos controlan directamente un determinado módulo (número de superiores inmediatos que posee)
Un módulo que controla a otro se dice que es "superordinado" a éste y, recíprocamente, un módulo controlado por otro se dice que es "subordinado".
Efectividad del Diseño
– Módulo
Módulo Superordinado
Módulo Subordinado
Fan-out : 2
Fan-in : 1
Efectividad del Diseño
– Módulos & Integración
N° Módulos
Costos
o Esfuerzo
Costo por Módulo
Costo por Integración
Costo Total SW
Costos Mínimos
Efectividad del Diseño
– Abstracción
“Cuando se considera una solución modular para enfrentar un problema, se puede plantear en distintos niveles de abstracción. Un nivel superior de Abstracción supone una solución en términos amplios, usando un lenguaje del entorno del problema. A un niveles más bajos, se toma una orientación más procedimental, se combina una terminologia orientada al problema con una orientada a la implementación. El nivel más bajo de abstracción permite que la solución pueda implementarse directamente”
Efectividad del Diseño
– Refinamiento
El refinamiento gradual es una estrategia de diseño top_down cuyo origen es la propuesta de Niklaus Wirth (WIRTH-71) quien postula que "La arquitectura de un programa se desarrolla refinando sucesivamente los niveles de detalle de los procedimientos. De este modo se desarrolla una jerarquía de procedimientos al descomponer sucesivamente una sentencia global hasta alcanzar sentencias específicas a nivel de un lenguaje de programación".
R. Pressman (PRESSMAN-88) al respecto cita a Wirth señalando que: "En cada etapa (del refinamiento), se descomponen una o varias de las instrucciones del programa dado en instrucciones cada vez más detalladas. Esta descomposición o refinamiento sucesivo termina cuando todas las intrucciones están expresadas en términos de cualquier lenguaje básico de computador o de programación.
Efectividad del Diseño
– Refinamiento
En el dominio de la Ingeniería de Software, la modularización se apoya en lo que se conoce como refinamiento sucesivo o gradual, para la configuración de la estructura del software que se precisa diseñar y luego construír.
Módulo A
Abstracción
Refinamiento
Gradual
A1
A2
Modularidad
Factorización
Factores de Calidad
– Acoplamiento
Corresponde al grado de independencia entre dos módulos. Entendido así, minimizar el acoplamiento aparece entonces como una determinante prioritaria al configurar las conformaciones estructurales.
La obtención de módulos tan independientes como sea posible,se puede ser lograda principalmente de tres maneras:
– Eliminando relaciones innecesarias.
– Reduciendo el número de relaciones necesarias.
– Debilitando la dependencia de las relaciones necesarias.
Factores de Calidad
– Cohesión
Corresponde a la medida de relación funcional de los elementos de un módulo, Los elementos de un módulo corresponden a instrucciones, definiciones de datos, o llamadas o otros módulos. La idea es organizar estos elementos de tal manera que tengan una mayor relación entre ellos a la hora de realizar la tarea específica del módulo
Factores de Calidad
Acoplamiento
Cohesión
Principios de un
Buen Diseño
Tipos de Acoplamiento
Acoplamiento Normal
Acoplamiento por Datos
Acoplamiento por Estampado o Imagen
Acoplamiento de Control
Acoplamiento Común
Acoplamiento por Contenido
Tipos de Acoplamiento
Grado de
Acoplamiento
NORMAL
Mejor Acoplamiento
DATOS
ESTAMPADO
CONTROL
EXTERNO (caso especial de COMÚN)
COMÚN
CONTENIDO
Tipos de Acoplamiento
Acoplamiento Normal
Dos Módulo A y B están Normalmente Acoplados si:
Un Módulo A llama a otro B
B retorna el control a A
No se produce traspaso de parámetros entre ellos, sólo existe la llamada de uno a otro.
A
B
Tipos de Acoplamiento
2. Acoplamiento por Datos
Dos módulos están acoplados por datos si ellos se comunican por parámetros, siendo cada parámetro una unidad elemental de datos
El acoplamiento por datos corresponde a la comunicación de datos necesaria entre módulos. Toda vez que los módulos tienen que comunicarse entre sí, la ligazón por datos es inevitable y serán adecuadas si se mantienen a niveles mínimos.
Obtener
Datos
Cliente
Leer Rut
Rut_cliente
Tipos de Acoplamiento
3. Acoplamiento por Estampado o Imagen
Dos módulos aparecen acoplados por estampado o ligados por imagen si ellos se refieren a la misma estructura datos local. Cabe destacar que por estructura de datos se debe entender un grupo compuesto de datos, tal como un registro, el cual, por su parte, se constituye de varios campos.
Calcular
Deuda
Cliente
Leer Cliente
Cliente
Cliente= rut+nombres+apellido_paterno+
Apellido_materno+dirección+fono+e_mail
Tipos de Acoplamiento
4. Acoplamiento de Control
Dos módulos están acoplados por control cuando uno de ellos pasa al otro módulo elementos de control (flags, switchs) como argumentos.
Provoca dependencia de ejecución entre un módulo y otro.
No es muy recomendable.
Obtener
Datos
Cliente
Leer Cliente
Cliente
Tipo_dato
Tipos de Acoplamiento
5. Acoplamiento Común
Los módulos presentan acoplamiento común, si ellos se refieren a la misma área estructura de datos (global). Cuando sólo se acomplan por una variable (global), se trata de un Acoplamiento Externo
Obtener
Nombre
Video
(Gp:) Leer Registro
Video
video
Actualizar
Stock
Video
Programas con muchos datos globales son extremadamente difíciles de entender por los programadores de mantención, porque no es fácil saber cuáles son los datos usados por un cierto módulo.
Tipos de Acoplamiento
6. Acoplamiento por Contenido
Este es un tipo de Acoplamiento Inaceptable. Dos módulos presentan acoplamiento de contenido (o patológico) si uno hace referencia al interior del otro. Esto ocurre si por ejemplo, en un módulo se desvía la secuencia de instrucciones al interior de otro o si un módulo altera un comando de otro.
Tal acoplamiento torna el concepto de módulos configurados bajo el criterio de la caja negra sin sentido, ya que fuerza a un módulo a conocer explícitamente los contenidos y la implementación de otro.
………..
………
………..
Jump to Srch
……….
………
A
………..
Srch: Move..
………..
……….
……….
………
B
Tipos de Acoplamiento
Dos módulos pueden estar relacionados por más de un tipo de acoplamiento. Si esto ocurre, el acoplamiento que caracteriza la relación entre ellos queda definido por el peor tipo que presenten. Por ejemplo, si dos módulos están ligados por acoplamiento de imagen y acoplamiento común a la vez, se dirá que los módulos están ligados por acoplamiento común.
Enfoques: ¿Cómo Analizar el Tipo de Acoplamiento?
Imaginar el Módulo como una Biblioteca
Cada Módulo es codificado por un programador diferente
Tipos de Cohesión
Grado de
Cohesión
FUNCIONAL
Mayor Cohesión
SECUENCIAL
COMUNICACIONAL
PROCEDURAL
TEMPORAL
LÓGICA
COINCIDENTAL
Módulo como
Caja Negra
Módulo
Transparente
STEVEN, MYERS, CONSTANTINE y YOURDON (1974)
establecieron "una escala de cohesión"
Tipos de Cohesión
1. Cohesión Funcional
Se puede decir que un módulo con cohesión funcional es aquel que contiene elementos que contribuyen a la ejecución de una y sólo una tarea relacionada al problema objeto de diseño,.
Ejemplos
Calcular el coseno de un ángulo
Calcular el I.V.A. De una factura
Verificar el dígito de un RUT
Tipos de Cohesión
2. Cohesión Secuencial
Un módulo secuencialmente cohesionado es aquel cuyos elementos están envueltos en actividades tales que los datos de salida de una actividad sirven como datos de entrada para la próxima actividad.
Ejemplo: Calcular Salario
1. Obtener sueldo base
2. Verificar número de cargas
3. Revisar días con permiso
4. Revisar días con licencia
5. Calcular horas de trabajo
6. Descontar horas de atraso
7. Agregar horas extras
….
Tipos de Cohesión
3. Cohesión Comunicacional
Un módulo presenta cohesión comunicacional cuando sus elementos contribuyen a actividades que usan la misma entrada o la misma salida. No importa el orden secuencial
Ejemplo: Obtener datos Video
1. Obtener nombre video
2. Obtener stock video
3. Obtener ubicación
4. Obtener precio
….
Tipos de Cohesión
4. Cohesión Procedimental
un módulo cohesionado por procedimientos es aquel cuyos elementos están envueltos en actividades diferentes y posiblemente no relacionadas, en donde el control fluye de una actividad a otra.
Ejemplos: Actividades en una oficina
1. Hablar por teléfono
2. Tomar un café
3. Leer correo electrónico
4. Solicitar cotización
….
Tipos de Cohesión
5. Cohesión Temporal
Un módulo con cohesión temporal es aquel cuyos elementos están envueltos en actividades que están relacionadas en función del momento en que se realizan.
Ejemplo: Actividades al iniciar el día
1. Apagar despertador
2. Tomar una ducha
3. Vestirse
4. Hacer la cama
5. Tomar desayuno
….
Tipos de Cohesión
6. Cohesión Lógica
Un módulo tiene cohesión lógica, cuando existe alguna relación entre los elementos del módulo, contribuyendo al desarrollo de actividades de una misma categoría general, donde la actividad o las actividades a ser ejecutadas se seleccionan desde fuera del módulo.
Ejemplo: Registrar Pago
1. Registrar pago con tarjeta de crédito
2. Registrar pago con cheque
3. Registrar pago con efectivo
….
Tipos de Cohesión
7. Cohesión Coincidental
Un módulo coincidentemente cohesionado es aquel cuyos elementos desarrollan actividades sin relación significativa entre sí.
Ejemplo:
1. Comprar un libro
2. Comer un trozo de torta
3. Ir al teatro
4. Lavar la ropa
5. Dormir
….
Árbol de Cohesión
Consideraciones Importantes para un Diseño de Calidad
La factorización consiste en separar la funcionalidad de un módulo, en subfunciones claramente identificables, en términos tales que sea posible considerarla como constitutiva de un módulo independiente.
1. La necesidad de reducir el tamaño de un módulo.
2. Obtener las ventajas de la modularización mediante un diseño "top_down". => Sistema más comprensible el sistema y facilitamiento de cambios
3. Evitar que una misma función aparezca en diferentes partes del sistema, es decir, en más de un módulo.
4. Proveer módulos de uso general.
5. Simplificar la implementación.
Reducir el Tamaño de un Módulo
1. De Marco señala, un tamaño razonable para un módulo corresponde a un conjunto de líneas de código de alrededor de media página de listado (30 líneas más o menos),
2. Page-Jones, señala que toda la codificación de un módulo debería, idealmente, ser visible en una página de listado (una exigencia que impone un límite no superior a 60 líneas)
3. Geral Weinberg (WEI-72) muestran que la habilidad del hombre para entender un módulo y encontrar errores depende de la capacidad de aprehender el módulo como un todo de una sola vez.
Resultados del Diseño
El proceso de diseño debe lograr la determinación de las directrizes en virtud de las cuales el producto de software ha de construirse, tomando como base la especificación de requerimientos generada en la fase de análisis. Así, entonces, el diseño, en cuanto proceso, debe dar como resultado:
el Diseño de la Arquitectura del producto de software a construir.
la Especificación de los Procedimientos del software a construir.
el Diseño de los Datos involucrados
el Diseño de la Interfaz de usuario
Diseño Arquitectónico
Diccionario de Datos
Clave_votante_válida: Flag que indica que la combinación ingresada por el cliente es válida, y puede llevar a emitir su voto.
Especificación de procesos
Interfaz
Nombre : REGISTRAR DATOS ACTUALIZACIÓN
Entradas : Datos_actualización
Salidas :Datos_actualización, datos_actualización_registrados.
Procedimiento:
Recibir Datos_actualización.
Abrir archivo INFORMACIÓN MUNICIPAL.
Escribir en archivo los Datos_actualización.
Cerrar archivo INFORMACIÓN MUNICIPAL.
Mandar mensaje indicando Datos_actualización_registrados.
Pseudocódigo
Diseño de Datos
Diseño de Datos
Diseño de Interfaz
Elementos del Diagrama de Estructura
Módulo
Obtener
Nombre
Video
(Gp:) Leer Registro
Video
Módulo
Predeterminado
MÓDULO JEFE
(INVOCADOR)
MÓDULO SUBORDINADO
(INVOCADO)
X
Y
Elementos del Diagrama de Estructura
Flujo de Control
Un almacén de datos corresponde a la instancia real
en la cual van a estar los datos que precisa el sistema
Un dispositivo físico es cualquier dispositivo
mediante el cual se puede recibir o enviar datos
necesarios para el sistema
Obtener
Datos
Cliente
Leer Cliente
Cliente
Tipo_dato
Flujo de Dato
Elementos del Diagrama de Estructura
Conectores
Elementos del Diagrama de Estructura
Secuencia
Iteración
Elementos del Diagrama de Estructura
Selección
Profundidad y Ancho de un Diagrama de Estructura
Profundidad y ancho proporcionan una idea del número de niveles de control y el ámbito global de control respectivamente.
El grado de salida es una medida del número de módulos que son controlados directamente por otro módulo.
El grado de entrada indica cuántos módulos controlan directamente un módulo dado.
Estrategia de Diseño para Construir Diagrama de Estructura
Diseño Centrado en Transformaciones
Diseño Centrado en Transacciones
DFD
Diagrama de
Estructura
Diseño
Análisis
Estrategia de Diseño
Diseño Centrado en Transformaciones
Los datos entran al sistema mediante caminos que se llaman flujos de entrada
En el núcleo ocurre la transformación de los datos, que entraron anteriormente
Finalmente los datos se mueven por caminos llamados flujos de salida
1.1
4.2
4.1
3
1.2
2.1
2.2
Flujo de Llegada
Centro
de
Transformación
Flujo de
Salida
Estrategia de Diseño
Diseño Centrado en Transacciones
Se presenta un centro de transacción, como centro de flujo de información
Desde el centro de flujo de Información, surgen muchos caminos de acción alternativos
Los caminos de acción alternativos, son de forma excluyentes
2.1
1
2.2
3.1
3.2
Camino de
Acción 1
4.1
4.2
Camino de
Acción 2
Camino de
Acción 3
Centro
de
Transacción
Estrategia de Diseño: Transformación
1. Revisión del Modelo Fundamental del sistema
DFD, mínimo tres niveles
2. Determinar si el DFD tiene características de Transformación o Transacción
Analizar el centro de transformación propiamente tal
3. Aislar el centro de Transformación, especificando los límites del flujo de llegada y de salida
Delimitar el centro de transformación (depende del diseñador)
4. Realizar el primer corte del diagrama de estructura
Primer nivel de factorización, se incorporan módulos coordinadores
Módulos a incorporar
Módulo principal Cp, que controla el resto de los módulos
Módulo coordinador de la Información de Entrada, Ce
Módulo controlador del centro de transformación, que supervisa las operaciones de los datos, Ct
Módulo controlador, del procesamiento de la información de salida, Cs
(Gp:) 1.1
(Gp:) 4.2
(Gp:) 4.1
(Gp:) 3
(Gp:) 1.2
(Gp:) 2.1
(Gp:) 2.2
(Gp:) Flujo de Llegada
(Gp:) Centro
de
Transformación
(Gp:) Flujo de
Salida
Cp
Cs
Ct
Ce
Diagrama de
Contexto
Nombres representativos
Estrategia de Diseño: Transformación
Estrategia de Diseño: Transformación
5. Ejecución del “segundo nivel de factorización”
(Gp:) 1.1
(Gp:) 4.2
(Gp:) 4.1
(Gp:) 3
(Gp:) 1.2
(Gp:) 2.1
(Gp:) 2.2
(Gp:) Flujo de Llegada
(Gp:) Centro
de
Transformación
(Gp:) Flujo de
Salida
Cp
Cs
Ct
Ce
2.2
2.1
1.1
1.2
Leer a
Leer b
a
b
4.1
4.2
3
Escribir
z
z
5. Ejecución del “segundo nivel de factorización”
6. Refinar la estructura obtenida, utilizando las guías, principios y conceptos, para un diseño de calidad
Aumentar o Disminuir el N° de módulos (ejemplo Ct)
Incorporar flujos de datos (DFD) y de control
7. Asegurarse del trabajo realizado, representado en el diseño construido
Verificar funcioanalidad, orden de módulos, etc.
Estrategia de Diseño: Transformación
Estrategia de Diseño: Transacción
1. Revisión del Modelo Fundamental del sistema
DFD, mínimo tres niveles
2. Determinar si el DFD tiene características de Transformación o Transacción
Analizar el centro de transacción propiamente tal
3. Aislar el centro de Transacción, especificando los límites del flujo de llegada y de salida
El centro de transacción se encuentra ligado al origen de varios caminos de información que fluyen radialmente de él
4. Realizar el primer corte del diagrama de estructura
Primer nivel de factorización, se incorporan módulos coordinadores
Módulos a incorporar
Módulo principal Cp, que controla el resto de los módulos
Módulo coordinador de la Información de Entrada, Ce
Módulo gestor del centro de transacción, D
Módulo controlador, los distintos caminos que generan información de salida,
Ci i =1—n (n: n° caminos)
Cp
D
C1
Ce
Estrategia de Diseño: Transacción
C2
C3
(Gp:) R
(Gp:) A
(Gp:) Q
(Gp:) D
(Gp:) P
(Gp:) a
(Gp:) z
(Gp:) b
Estrategia de Diseño: Transacción
5. Ejecución del “segundo nivel de factorización”
Cp
Ce
R
P
Q
Leer a
Leer b
a
Escribir
z
5. Ejecución del “segundo nivel de factorización”
R
A
Q
D
P
a
z
b
Camino 1
Camino 2
Camino 3
D
C1
C2
C3
6. Refinar la estructura obtenida, utilizando las guías, principios y conceptos, para un diseño de calidad
Aumentar o Disminuir el N° de módulos
Incorporar flujos de datos (DFD) y de control
7. Asegurarse del trabajo realizado, representado en el diseño construido
Verificar funcionalidad, orden de módulos, etc.
Estrategia de Diseño: Transacción
Diseño Procedimental (Diseño Detallado
Especificación Interfaz-Función
Especificación Mediante las Miniespecificaciones del Análisis
Especificación por Pseudocódigo
Diseño Detallado
1. Especificación por interfaz-función
Permite definir un módulo sin entrar en excesivos detalles. La interfaz del módulo contiene los parámetros de entrada y de salida, mientras la función del módulo describe las tareas que este lleva a cabo. Se permite el uso de tablas, fórmulas, lenguaje natural, etc. Permite variar el grado de formalismo en la definición del módulo, generalmente, dando bastante libertad a los programadores. Su inclusión como comentario en el código final facilita el mantenimiento.
Ejemplo:
Módulo: SELECCIONAR ASIENTO DE PASAJERO
Entrada: PREFERENCIA_ASIENTO_PONDERADA
Salidas: ASIENTO_SELECCIONADO, PREFERENCIA_DISPONIBLE
Función: Seleccionar un asiento para un pasajero considerando que sus preferencias de ubicación sean lo más cercanas (ponderadamente) al asiento elegido.
Diseño Detallado
2. Especificación Mediante las Miniespecificaciones del Análisis
Este método considera que las miniespecificaciones generadas durante la fase de análisis sirven también como especificación de módulos. Se considera, en general, que la especificación de cada burbuja del diagrama de flujo de datos es suficiente para especificar lo que en la fase siguiente al diseño se debe construir. La gran limitación de este método es que no siempre existe una correspondencia uno a uno entre las burbujas, explicitadas como necesarias de automatizar en la fase de análisis, y los módulos del diagrama de estructura.
Módulo: SELECCIONAR ASIENTO DE PASAJERO
Entrada: PREFERENCIA_ASIENTO_PONDERADA
Salidas: ASIENTO_SELECCIONADO, PREFERENCIA_DISPONIBLE
Función: Seleccionar un asiento para un pasajero considerando que sus preferencias deubicación sean lo más cercanas (ponderadamente) al asiento elegido.
Detalles de Funcionalidad
· Buscar asiento disponible comenzando con la clase solicitada y continuando con clases inferiores.
· Anotar para cada asiento la diferencia respecto a la preferencia del cliente.
· Seleccionar el asiento con menor diferencia: este será el Asiento-Seleccionado.
(Diferencia=Dif-Fumador*PESO_FUMADOR+ …)
· Si el cliente necesita un asiento no fumador (y Peso-Fumador > 1) y ha sido
seleccionado un asiento fumador, intentar mover en una fila atrás la sección de no fumadores en la clase del cliente (si es posible).
· Si la diferencia entre el asiento preferido y el asiento seleccionado es 0, realizar la asignación PREFERENCIA-DISPONIBLE=”Y”; de lo contrario asígnele “N”.
Diseño Detallado
2. Especificación por pseudocódigo
Pseudocódigo es un lenguaje informal similar al lenguaje estructurado, el cual es más preciso y detallado que la especificación por interfaz-función. Tiene sintaxis fija para constructores, declaración de datos y módulos, y sintaxis libre para describir características de procesamiento
 Página anterior | Volver al principio del trabajo | Página siguiente  |